1
2
следующий
Проще говоря, git pull выполняет git fetch, за которым следует git merge.
Вы можете выполнить git fetch в любое время, чтобы обновить ветки удаленного отслеживания в разделе refs / remotes / /.
Эта операция никогда не изменяет ни одну из ваших собственных локальных веток в разделе refs / head, и ее можно безопасно выполнять без изменения вашей рабочей копии. Я даже слышал о людях, периодически запускающих git fetch в задании cron в фоновом режиме (хотя я бы не рекомендовал это делать).
Git pull - это то, что вы должны сделать, чтобы обновить локальную ветку до ее удаленной версии, а также обновить другие ветки удаленного отслеживания.
Из документации Git для git pull:
В режиме по умолчанию git pull является сокращением для git fetch, за которым следует git merge FETCH_HEAD.
|
Когда вы используете pull, Git пытается автоматически делать вашу работу за вас. Он зависит от контекста, поэтому Git объединит любые извлеченные коммиты в ветку, в которой вы сейчас работаете. Pull автоматически объединяет коммиты, не позволяя вам предварительно их просмотреть. Если вы плохо управляете своими филиалами, вы можете часто сталкиваться с конфликтами.
Когда вы выполняете выборку, Git собирает все коммиты из целевой ветки, которых нет в вашей текущей ветке, и сохраняет их в вашем локальном репозитории. Однако он не объединяет их с вашей текущей веткой. Это особенно полезно, если вам нужно поддерживать репозиторий в актуальном состоянии, но вы работаете над чем-то, что может сломаться, если вы обновите свои файлы.
Чтобы интегрировать коммиты в основную ветку, вы используете слияние.
|
Важно противопоставить философию дизайна git философии более традиционного инструмента управления версиями, такого как SVN.
Subversion была разработана и построена по модели клиент / сервер. Существует один репозиторий, который является сервером, и несколько клиентов могут получать код с сервера, работать с ним, а затем передавать его обратно на сервер. Предполагается, что клиент всегда может связаться с сервером, когда ему нужно выполнить операцию.
Git был разработан для поддержки более распределенной модели без необходимости в центральном репозитории (хотя вы, безусловно, можете использовать его, если хотите). Также git был спроектирован таким образом, что клиенту и «серверу» не нужно быть в сети одновременно. Git был разработан таким образом, чтобы люди, перешедшие по ненадежной ссылке, могли обмениваться кодом даже по электронной почте. Можно работать полностью автономно и записать компакт-диск для обмена кодом через git.
Для поддержки этой модели git поддерживает локальный репозиторий с вашим кодом, а также дополнительный локальный репозиторий, который отражает состояние удаленного репозитория. Сохраняя копию удаленного репозитория локально, git может определить необходимые изменения, даже если удаленный репозиторий недоступен. Позже, когда вам нужно будет отправить изменения кому-то еще, git может передать их как набор изменений с момента времени, известного удаленному репозиторию.
git fetch - это команда, которая говорит «обновить мою локальную копию удаленного репозитория».
git pull говорит: «перенесите изменения в удаленном репозитории туда, где я храню свой собственный код».
Обычно git pull делает это, выполняя git fetch, чтобы обновить локальную копию удаленного репозитория, а затем объединять изменения в ваш собственный репозиторий кода и, возможно, вашу рабочую копию.
Важно помнить, что часто на вашей рабочей станции находится не менее трех копий проекта. Одна копия - это ваш собственный репозиторий с вашей собственной историей коммитов. Вторая копия - это ваша рабочая копия, которую вы редактируете и создаете. Третья копия - это ваша локальная «кешированная» копия удаленного репозитория.
|
Вот изображение Оливером Стилом того, как все это сочетается:
Если есть достаточный интерес, я могу обновить изображение, добавив git clone и git merge ...
|
Один из вариантов использования git fetch заключается в том, что следующее будет сообщать вам о любых изменениях в удаленной ветке с момента вашего последнего извлечения ... так что вы можете проверить перед выполнением фактического извлечения, которое может изменить файлы в вашей текущей ветке и рабочей копии.
git fetch
git diff ... origin
См .: https://git-scm.com/docs/git-diff относительно синтаксиса с двумя и тремя точками в команде diff
|
Мне немного пришлось понять, в чем разница, но это простое объяснение. master на вашем локальном хосте - это ветка.
Когда вы клонируете репозиторий, вы загружаете весь репозиторий на локальный хост. Это означает, что в это время у вас есть указатель origin / master на HEAD и master, указывающие на один и тот же HEAD.
когда вы начинаете работать и делаете коммиты, вы перемещаете главный указатель на HEAD + ваши коммиты. Но указатель origin / master все еще указывает на то, что было при клонировании.
Так что разница будет:
Если вы выполните git fetch, он просто получит все изменения в удаленном репозитории (GitHub) и переместит указатель origin / master на HEAD. Тем временем мастер вашего местного филиала будет продолжать указывать, где он находится.
Если вы выполните git pull, он в основном выполнит выборку (как объяснялось ранее) и объединит любые новые изменения в вашmaster и переместите указатель на HEAD.
|
Иногда помогает визуальное представление.
|
Вкратце
git fetch похож на pull, но не объединяется. т.е. он получает удаленные обновления (ссылки и объекты), но ваш локальный остается неизменным (т.е. origin / master обновляется, но master остается тем же).
git pull снимает с пульта и мгновенно объединяется.
Больше
git clone клонирует репо.
git rebase сохраняет данные из вашей текущей ветки, которые не находятся в восходящей ветке, во временную область. Ваша ветка теперь такая же, как и до того, как вы начали вносить изменения. Итак, git pull -rebase загрузит удаленные изменения, перемотает вашу локальную ветку, воспроизведет ваши изменения поверх текущей ветки один за другим, пока вы не обновите.
Кроме того, git branch -a точно покажет, что происходит со всеми вашими ветвями - локальными и удаленными.
Эта запись в блоге была полезной:
Разница между git pull, git fetch и git clone (и git rebase) - Майк Пирс
и охватывает git pull, git fetch, git clone и git rebase.
====
ОБНОВИТЬ
Я подумал, что обновлю это, чтобы показать, как вы на самом деле используете это на практике.
Обновите локальное репо с пульта дистанционного управления (но не объединяйте):
git fetch
Скачав обновления, посмотрим на отличия:
git diff мастер происхождения / мастер
Если вас устраивают эти обновления, объедините:
git pull
Примечания:
На шаге 2: Дополнительные сведения о различиях между локальным и удаленным устройством см. В разделе: Как сравнить локальную ветвь git с ее удаленной веткой?
На шаге 3: Вероятно, более точным (например, при быстро меняющемся репо) будет сделать здесь git rebase origin. См. Комментарий @Justin Ohms в другом ответе.
См. Также: http://longair.net/blog/2009/04/16/git-fetch-and-merge/
|
git-pull - извлечь и объединить с другим репозиторием или локальной веткой
ОБЗОР
git pull…
ОПИСАНИЕ
Запускает git-fetch с заданными параметрами и вызывает git-merge для объединения
извлечены головы в текущую ветку. С --rebase вызывает git-rebase
вместо git-merge.
Обратите внимание, что вы можете использовать. (текущий каталог) как <репозиторий> для извлечения
из локального репозитория - это полезно при объединении локальных веток
в текущую ветку.
Также обратите внимание, что параметры, предназначенные для самого git-pull и основного git-merge
должны быть указаны перед параметрами, предназначенными для git-fetch.
Вы бы вытащили, если хотите, чтобы истории были объединены, вы бы получили, если вам просто «нужен код», поскольку какой-то человек пометил некоторые статьи здесь.
|
Вы можете получить данные из удаленного репозитория, увидеть различия, а затем извлечь или объединить.
Это пример удаленного репозитория с именем origin и ветки с именем master, отслеживающей источник / мастер удаленной ветки:
мастер проверки git
git fetch
git diff origin / master
git rebase origin master
|
Короткий и простой ответ: git pull - это просто git fetch, за которым следует git merge.
Очень важно отметить, что git pull автоматически объединится, нравится вам это или нет. Это, конечно, может привести к конфликтам слияния. Допустим, ваш пульт - источник, а ваша ветка - мастер. Если перед загрузкой вы выполните команду git diff origin / master, вы должны иметь некоторое представление о потенциальных конфликтах слияния и соответственно подготовить свою локальную ветку.
В дополнение к вытягиванию и выталкиванию некоторые рабочие процессы включают в себя git rebase, например этот, который я перефразирую из связанной статьи:
git pull origin master
git checkout foo-branch
git rebase master
git push origin foo-branch
Если вы окажетесь в такой ситуации, у вас может возникнуть соблазн использовать git pull --rebase. Если вы действительно, действительно знаете, что делаете, я бы посоветовал этого не делать. Это предупреждение взято со страницы руководства для git-pull версии 2.3.5:
Это потенциально опасный режим работы. Он переписывает
история, что не сулит ничего хорошего, когда вы опубликовали эту историю
уже. Не используйте эту опцию, если вы не прочитали git-rebase (1)
внимательно.
|
Хорошо, вот некоторая информация о git pull и git fetch, чтобы вы могли понять фактические различия ... несколькими простыми словами, fetch получает последние данные, но не изменения кода и не собираются связываться с вашим текущим кодом локальной ветки , но потяните, получите изменения кода и объедините его в свою локальную ветвь, прочтите, чтобы получить более подробную информацию о каждом:
git fetch
Он загрузит все ссылки и объекты, а также любые новые ветки в ваш локальный репозиторий ...
Получать ветки и / или теги (совместно именуемые "ссылки") из одного или нескольких
другие репозитории, а также объекты, необходимые для завершения их
истории. Обновлены ветки удаленного отслеживания (см. Описание
ниже, чтобы узнать о способах управления этим поведением).
По умолчанию любой тег, указывающий на извлекаемые истории, является
также получил; эффект заключается в получении тегов, указывающих на ветви,
вас интересует. Это поведение по умолчанию можно изменить с помощью
параметры --tags или --no-tags или настроив
remote..tagOpt. Используя refspec, который явно выбирает теги,
вы можете получать теги, которые не указывают на интересующие вас ветки
в тоже.
git fetch может получить излибо единый именованный репозиторий, либо URL, либо
сразу из нескольких репозиториев, если задано и есть
пульты. запись в конфигурационном файле. (См. Git-config1).
Если удаленный пульт не указан, по умолчанию исходный пульт будет
используется, если для текущего
филиал.
Имена получаемых ссылок вместе с именами объектов.
они указывают на, записываются в .git / FETCH_HEAD. Эта информация может быть
используется скриптами или другими командами git, такими как git-pull.
git pull
Он применит изменения с удаленного к текущей ветке в локальном ...
Включает изменения из удаленного репозитория в текущую ветку.
В режиме по умолчанию git pull - это сокращение от git fetch, за которым следует
git merge FETCH_HEAD.
Точнее, git pull запускает git fetch с заданными параметрами и
вызывает git merge для слияния извлеченных заголовков веток с текущими
филиал. С --rebase запускается git rebase вместо git merge.
должно быть именем удаленного репозитория, переданным в
git-fetch1. может назвать произвольную удаленную ссылку (например,
имя тега) или даже набор ссылок с соответствующими
ветки удаленного отслеживания (например, refs / Heads /: refs / remotes / origin /),
но обычно это имя ветки в удаленном репозитории.
Значения по умолчанию для и считываются из
"удаленная" и "объединенная" конфигурация для текущей ветви, установленная
git-branch --track.
Я также создаю изображение ниже, чтобы показать вам, как git fetch и git pull работают вместе ...
|
Это интерактивное графическое представление очень полезно для понимания git: http://ndpsoftware.com/git-cheatsheet.html
git fetch просто «загружает» изменения с пульта дистанционного управления в ваш локальный репозиторий. git pull загружает изменения и объединяет их в вашу текущую ветку. «В режиме по умолчанию git pull - это сокращение от git fetch, за которым следует git merge FETCH_HEAD».
|
Бонус:
Говоря о pull & fetch в приведенных выше ответах, я хотел бы поделиться интересным трюком,
git pull --rebase
Эта команда выше - самая полезная команда в моей жизни с git, которая сэкономила много времени.
Прежде чем отправлять новые коммиты на сервер, попробуйте эту команду, и она автоматически синхронизирует последние изменения сервера (с помощью fetch + merge) и поместит вашу фиксацию вверху в журнале git. Не нужно беспокоиться о ручном извлечении / слиянии.
Подробности см. На сайте: http://gitolite.com/git-pull--rebase.
|
Мне нравится визуальное представление ситуации, чтобы понять эти вещи. Возможно, другие разработчики тоже захотят это увидеть, поэтому вот мое дополнение. Я не совсем уверен, что все это правильно, поэтому, пожалуйста, прокомментируйте, если вы обнаружите какие-либо ошибки.
МЕСТНАЯ СИСТЕМА
. ================================================== ===
=================. ================= =================== =============
УДАЛЕННОЕ ХРАНИЛИЩЕ. РАБОЧАЯ КОПИЯ УДАЛЕННОГО ХРАНИЛИЩА ЛОКАЛЬНЫЙ РЕПОЗИТОРИЙ
(ПРОИСХОЖДЕНИЕ). (ЗАПИСАНО)
например, . зеркало
репозиторий на github. . удаленное репо
Так же может быть .
множественные репо.
.
.
ПОЛУЧИТЬ * ------------------> *
Ваш локальный кеш пульта дистанционного управления обновляется с указанием источника (или нескольких
внешние источники, то есть распределенная природа git)
.
ВЫТАЩИТЬ *------------------------------------------------ --------> *
изменения добавляются прямо в вашу локальную копию. когда возникают конфликты,
вас просят о решениях.
.
COMMIT. * <--------------- *
Придя, например, к подрывной деятельности, вы можете подумать, что фиксация
обновит происхождение. В git фиксация выполняется только для вашего локального репо.
.
НАЖАТЬ * <--------------------------------------- *
Синхронизирует ваши изменения обратно в источник.
Некоторые основные преимущества получения зеркала пульта дистанционного управления:
Производительность (пролистайте все коммиты и сообщения, не пытаясь протолкнуть его по сети)
Отзыв о состоянии вашего локального репо (например, я использую SourceTree Atlassian, который покажет мне лампочку, указывающую, совершаю ли я вперед или назад по сравнению с источником. Эта информация может быть обновлена с помощью GIT FETCH).
|
Я тоже боролся с этим. Фактически, я попал сюда с поиском в Google точно такого же вопроса. Прочитав все эти ответы, я, наконец, нарисовал картину в моей голове, и я решил попытаться понять это, глядя на состояние 2 репозиториев и 1 песочницы и действия, выполняемые с течением времени, при просмотре их версии. Вот что я придумал. Пожалуйста, поправьте меня, если я где-то напортачил.
Три репозитория с выборкой:
--------------------- ----------------------- ------ -----------------
- Удаленное репо - - Удаленное репо - - Удаленное репо -
- - - толкается - - -
- @ R01 - - @ R02 - - @ R02 -
--------------------- ----------------------- ------ -----------------
--------------------- ----------------------------------------------
- Местное репо - - Местное репо - - Местное репо -
- тянуть - - - - извлекать -
- @ R01 - - @ R01 - - @ R02 -
--------------------- ----------------------- ------ -----------------
--------------------- ----------------------- ------ -----------------
- Локальная песочница - - Локальная песочница - - Локальная песочница -
- Расчет - - новые работы - - -
- @ R01 - - @ R01 + - - @ R01 + -
--------------------- ----------------------- ------ -----------------
Три репо с натяжкой
--------------------- ----------------------- ------ -----------------
- Удаленное репо - - Удаленное репо - - Удаленное репо -
- - - толкается - - -
- @ R01 - - @ R02 - - @ R02 -
--------------------- ----------------------- ------ -----------------
--------------------- ----------------------- ------ -----------------
- Местное репо - - Местное репо - - Местное репо -
- тянуть - - - - тянуть -
- @ R01 - - @ R01 - - @ R02 -
--------------------- ----------------------- ------ -----------------
--------------------- ----------------------- ------ -----------------
- Локальная песочница - - Локальная песочница - - Локальная песочница -
- Оформление заказа - - Выполнена новая работа - - объединено с R02 -
- @ R01 - - @ R01 + - - @ R02 + -
--------------------- ----------------------- ------ -----------------
Это помогло мне понять, почему выборка так важна.
|
Разницу между GIT Fetch и GIT Pull можно объяснить следующим сценарием:
(Имея в виду, что изображения говорят громче, чем слова !, я предоставил графическое изображение)
Возьмем пример, когда вы работаете над проектом с членами своей команды. Таким образом, будет одна основная ветвь проекта, и все участники должны разветвить ее в свой локальный репозиторий, а затем поработать над этой локальной ветвью, чтобы изменить / добавить модули, а затем вернуться в основную ветвь.
Так,
Исходное состояние двух ветвей, когда вы разветвляете основной проект в локальном репозитории, будет таким: (A, B и C - это уже завершенные модули проекта)
Теперь вы начали работу над новым модулем (предположим, D), и когда вы завершили модуль D, вы хотите отправить его в основную ветку, но тем временем происходит то, что один из ваших товарищей по команде разработал новый модуль E, F и модифицированный C.
Итак, теперь произошло то, что в вашем локальном репозитории не хватает исходного прогресса проекта, и, таким образом, внесение ваших изменений в основную ветвь может привести к конфликту и может вызвать сбой в работе вашего модуля D.
Чтобы избежать таких проблем и работать параллельно с исходным ходом проекта, есть два способа:
1. Git Fetch - загрузит все изменения, внесенные в проект исходной / основной ветки, которых нет в вашей локальной ветке. И будет ждать, пока команда Git Merge применит изменения, внесенные в ваш репозиторий или ветку.
Итак, теперь вы можете внимательно следить за файлами, прежде чем объединять их в свой репозиторий. И вы также можете изменить D, если это необходимо, из-за Modified C.
2. Git Pull - это обновит вашу локальную ветку с помощью исходной / основной ветки, т.е. фактически то, что она делает, представляет собой комбинацию Git Fetch и Git слияния одного за другим.
Но это может вызвать конфликты, поэтому рекомендуется использовать Git Pull с чистой копией.
|
Мы просто говорим:
git pull == git fetch + git merge
Если вы запустите git pull, вам не нужно объединять данные с локальными. Если вы запустите git fetch, это означает, что вы должны запустить git merge, чтобы получить последний код на свой локальный компьютер. В противном случае локальный машинный код не будет изменен без слияния.
Итак, в Git Gui, когда вы выполняете выборку, вам нужно объединить данные. Сам Fetch не будет вносить изменения в код на вашем локальном компьютере. Вы можете проверить это при обновлении кода, загрузив
однажды принеси и увидишь; код не изменится. Затем вы объединяете ... Вы увидите измененный код.
|
git fetch переносит код с удаленного сервера в ветки отслеживания в локальном репозитории. Если ваш пульт называется origin (по умолчанию), то эти ветки будут внутри origin /, например origin / master, origin / mybranch-123 и т. Д. Это не ваши текущие ветки, это локальные копии этих веток с сервера. .
git pull выполняет git fetch, но затем также объединяет код из ветки отслеживания с вашим текущимлокальная версия этой ветки. Если вы еще не готовы к этим изменениям, просто сначала выполните git fetch.
|
git fetch получит удаленные ветки, чтобы вы могли git diff или git объединить их с текущей веткой. git pull запустит выборку на удаленном плече, отслеживаемом текущей веткой, а затем объединит результат. Вы можете использовать git fetch, чтобы узнать, есть ли какие-либо обновления в удаленной ветке, без необходимости их объединения с вашей локальной веткой.
|
Git Fetch
Вы загружаете изменения в локальную ветку из источника через выборку. Fetch запрашивает у удаленного репо все коммиты, которые сделали другие, но у вас нет в вашем локальном репо. Fetch загружает эти коммиты и добавляет их в локальный репозиторий.
Git Merge
Вы можете применить изменения, загруженные через выборку, с помощью команды слияния. Слияние примет коммиты, полученные из выборки, и попытается добавить их в вашу локальную ветку. Слияние сохранит историю фиксации ваших локальных изменений, поэтому, когда вы поделитесь своей веткой с помощью push, Git будет знать, как другие могут объединить ваши изменения.
Git Pull
Извлечение и слияние выполняются вместе достаточно часто, чтобы была создана команда, объединяющая их, pull. Pull выполняет выборку, а затем слияние, чтобы добавить загруженные коммиты в вашу локальную ветку.
|
Проще говоря, если вы собирались сесть на самолет без подключения к Интернету ... перед вылетом вы могли бы просто выполнить git fetch origin . Он загрузит все изменения на ваш компьютер, но сохранит его отдельно от вашей локальной разработки / рабочего пространства.
В самолете вы можете внести изменения в свое локальное рабочее пространство, а затем объединить его с тем, что вы получили, и разрешить потенциальные конфликты слияния без подключения к Интернету. И если кто-то не внес новые изменения в удаленный репозиторий, то, когда вы прибудете в пункт назначения, вы должны выполнить git push origin и пойти за кофе.
Из этого замечательного учебника по Atlassian:
Команда git fetch загружает коммиты, файлы и ссылки из
удаленный репозиторий в ваш локальный репозиторий.
Получение - это то, что вы делаете, когда хотите увидеть, что есть у всех
работал над. Это похоже на обновление SVN в том, что позволяет вам видеть
как продвигалась центральная история, но это не заставляет вас
фактически объединить изменения в ваш репозиторий. Git изолирует
извлекли контент как из существующего локального контента, он абсолютно
не влияет на ваши местные разработки. Полученный контент необходимо явно проверить с помощью команды git checkout. Это делает
получение безопасного способа просмотра коммитов перед их интеграцией с
ваш локальный репозиторий.
При загрузке содержимого из удаленного репозитория для выполнения этой задачи доступны команды git pull и git fetch. Вы можете рассмотреть
git получить "безопасную" версию двух команд. Он загрузит
удаленный контент, но не обновлять рабочее состояние локального репозитория,
оставив свою текущую работу без изменений. git pull более агрессивен
альтернативно, он загрузит удаленный контент для активного локального
ветвь и немедленно выполните git merge, чтобы создать коммит слияния
для нового удаленного контента. Если у вас есть незавершенные изменения
это вызовет конфликты и запустит разрешение конфликта слияния
течь.
С помощью git pull:
Вы не получаете изоляции.
Это не требует явной проверки. Потому что он неявно выполняет слияние git.
Шаг слияния повлияет на ваше местное развитие и может вызвать конфликты.
Это в основном НЕ безопасно. Это агрессивно.
В отличие от git fetch, где он влияет только на ваши .git / refs / remotes, git pull повлияет как на ваши .git / refs / remotes, так и на .git / refs / head /
Хммм ... так что, если я не обновляю рабочую копию с помощью git fetch, то где мне делать изменения? Где Git fetch хранит новые коммиты?
Отличный вопрос. Он помещает его где-нибудь изолированно от вашей рабочей копии. Но опять же где? Давайте узнаем.
В каталоге вашего проекта (т.е. там, где вы выполняете свои команды git) выполните:
ls. Это покажет файлы и каталоги. Я знаю, ничего крутого.
Теперь выполните ls -a. Это покажет точечные файлы, то есть файлы, начинающиеся с. После этого вы увидите каталог с именем: .git.
Сделайте cd .git. Очевидно, это изменит ваш каталог.
А теперь самое интересное. делать ls. Вы увидите список каталогов. Ищем реф. Сделайте cd refs.
Интересно посмотреть, что находится внутри всех каталогов, но давайте остановимся на двух из них. головы и пульты. Используйте компакт-диск, чтобы проверить их также.
Любой выполненный вами git fetch обновит элементы в каталоге /.git/refs/remotes. Он ничего не обновит в каталоге /.git/refs/heads.
Любой git pull сначала выполнит git fetch, обновит элементы в каталоге /.git/refs/remotes, затем объединится с вашим локальным, а затем изменит заголовок внутри каталога /.git/refs/heads.
Очень хороший ответ по теме также можно найти в разделе «Где размещается git fetch?».
Также ищите «Обозначение косой черты» в сообщении о правилах именования веток Git. Это поможет вам лучше понять, как Git размещает вещи вразные каталоги.
Чтобы увидеть настоящую разницу
Просто делать:
мастер происхождения git fetch
мастер проверки git
Если удаленный мастер был обновлен, вы получите такое сообщение:
Ваша ветка отстает от origin / master на 2 коммита и может быть быстро перенаправлена.
(используйте "git pull", чтобы обновить локальную ветку)
Если вы не получили и просто выполнили git checkout master, ваш локальный git не узнает, что добавлены 2 фиксации. И он просто сказал бы:
Уже на мастере
В вашей ветке обновлено значение origin / master.
Но это устарело и неверно. Это потому, что git будет давать вам обратную связь исключительно на основе того, что ему известно. Он не обращает внимания на новые коммиты, которые еще не сняты ...
Есть ли способ увидеть новые изменения, внесенные удаленно, при локальной работе в ветке?
Некоторые IDE (например, Xcode) очень умны и используют результат git fetch и могут аннотировать строки кода, которые были изменены в удаленной ветке вашей текущей рабочей ветки. Если эта строка была изменена как локальными изменениями, так и удаленной ветвью, она помечается красным цветом. Это не конфликт слияния. Это потенциальный конфликт слияния. Это заголовок, который вы можете использовать для разрешения будущего конфликта слияния, прежде чем выполнять git pull из удаленной ветки.
Веселый совет:
Если вы выбрали удаленную ветку, например сделал:
git fetch origin feature / 123
Затем это войдет в ваш каталог пультов дистанционного управления. Он по-прежнему недоступен в вашем локальном каталоге. Однако это упрощает оформление заказа в эту удаленную ветку с помощью DWIM (делайте то, что я имею в виду):
функция проверки git / 123
вам больше не нужно:
git checkout -b функция / 123 происхождение / функция / 123
Подробнее об этом читайте здесь
|
Единственная разница между git pull и git fetch заключается в следующем:
git pull извлекает из удаленной ветки и объединяет ее.
git fetch извлекает только из удаленной ветки, но не объединяет
то есть git pull = git fetch + git merge ...
|
Git позволяет применять более старые коммиты в хронологическом порядке после новых.
Из-за этого процесс передачи коммитов между репозиториями разбивается на два этапа:
Копирование новых коммитов из удаленной ветки в копию этой удаленной ветки внутри локального репо.
(операция репо в репо) master @ remote >> remote / origin / master @ local
Интеграция новых коммитов в локальную ветку
(операция внутри репо) remote / origin / master @ local >> master @ local
Есть два способа выполнить шаг 2. Вы можете:
Разветвляйте локальную ветвь после последнего общего предка и добавляйте новые коммиты параллельно с коммитами, которые уникальны для локального репозитория, завершаются слиянием фиксации, закрывая вилку.
Вставьте новые коммиты после последнего общего предка и повторно примените коммиты, уникальные для локального репозитория.
В терминологии git шаг 1 - это git fetch, шаг 2 - git merge или git rebase
git pull - это git fetch и git merge
|
Git получает ветку последней версии с удаленного на локальный с помощью двух команд:
git fetch: Git собирается получить последнюю версию с удаленного на локальный, но он не объединяется автоматически.
мастер происхождения git fetch
git log -p master..origin / master
git merge origin / master
Приведенные выше команды означают, что загружайте последнюю версию основной ветки из источника с удаленного в исходную главную ветвь. А затем сравнивает локальную главную ветвь и исходную главную ветку. Наконец, слияние.
git pull: Git получит последнюю версию с удаленного компьютера и объединится с локальным.
git pull origin master
Приведенная выше команда эквивалентна git fetch и git merge. На практике git fetch может быть более безопасным, потому что перед слиянием мы можем увидеть изменения и решить, следует ли выполнять слияние.
|
В чем разница между git pull и git fetch?
Чтобы понять это, вам сначала нужно понять, что ваш локальный git поддерживает не только ваш локальный репозиторий, но также поддерживает локальную копию удаленного репозитория.
git fetch обновляет вашу локальную копию удаленного репозитория. Например, если ваш удаленный репозиторий - GitHub, вы можете получить любые изменения, сделанные в удаленном репозитории, в вашу локальную копию этого удаленного репозитория. Это позволит вам выполнять такие операции, как сравнение или слияние.
git pull, с другой стороны, перенесет изменения в удаленном репозитории туда, где вы храните свой собственный код. Как правило, git pull сначала выполняет git fetch, чтобы обновить локальную копию удаленного репозитория, а затем объединяет изменения в ваш собственный репозиторий кода и, возможно, вашу рабочую копию.
|
git pull == (git fetch + git merge)
git fetch не меняет локальные ветки.
Если у вас уже есть локальный репозиторий с удаленной настройкой для желаемого проекта, вы можете получить все ветки и теги для существующего удаленного с помощью git fetch. ... Fetch не вносит никаких изменений в локальные ветки, поэтому вам нужно будет объединить удаленную ветвь с парной локальной ветвью, чтобы включить новые изменения выборки. из github
|
Простое графическое представление для начинающих,
Вот,
git pull
получит кодиз репозитория и перебазировать с вашим локальным ... в git pull есть возможность создания новых коммитов.
но в ,
git fetch
будет извлекать код из репозитория, и нам нужно перебазировать его вручную с помощью git rebase
например: я собираюсь получить от мастера сервера и переустановить его на моем локальном мастере.
1) git pull (перебазирование будет выполнено автоматически):
git pull origin master
здесь origin - ваш удаленный мастер репо - ваша ветка
2) git fetch (необходимо перебазировать вручную):
мастер происхождения git fetch
он будет получать изменения сервера из источника. и он будет в вашем локальном, пока вы не переустановите его самостоятельно. нам нужно устранять конфликты вручную, проверяя коды.
git перебазировать происхождение / мастер
это переведет код в локальный. перед этим убедитесь, что вы находитесь в нужной ветке.
|
Стараюсь быть ясным и простым.
Команда git pull на самом деле является ярлыком для git fetch, за которым следует команда git merge или git rebase в зависимости от вашей конфигурации. Вы можете настроить свой репозиторий Git так, чтобы git pull выполнял выборку с последующей перебазированием.
|
Фактически Git поддерживает копию вашего собственного кода и
удаленный репозиторий.
Команда git fetch обновляет вашу локальную копию, получая данные из удаленного репозитория. Причина, по которой нам это нужно, заключается в том, что кто-то другой мог внести некоторые изменения в код, а вы хотите постоянно обновляться.
Команда git pull переносит изменения в удаленном репозитории туда, где вы храните свой собственный код. Обычно git pull делает это, сначала выполняя «git fetch», чтобы обновить локальную копию удаленного репозитория, а затем объединяет изменения в ваш собственный репозиторий кода и, возможно, вашу рабочую копию.
|
1
2
следующий
Весьма активный вопрос. Заработайте 10 репутации, чтобы ответить на этот вопрос. Требование репутации помогает защитить этот вопрос от спама и отсутствия ответов.
Не тот ответ, который вы ищете? Просмотрите другие вопросы с меткой git version-control git-pull git-fetch или задайте свой вопрос.